feat: implement blob/retrieve capability#284
Conversation
frrist
left a comment
frrist
left a comment
There was a problem hiding this comment.
Please see comments in pkg/service/retrieval/ucan/blob_retrieve.go, they are non-blocking, but I'd like a bit of discussion before merge.
I have a hunch this test failure:
=== RUN TestFXBlobRetrieve/blob/retrieve
ucan_fx_test.go:196:
Error Trace: /Users/runner/work/piri/piri/pkg/service/retrieval/ucan_fx_test.go:196
Error: Received unexpected error:
sending message: doing HTTP request: Get "http://localhost:8080/piece/bafkreigrspvthgxgp4uxx3v4y7oo3cu3cxucoolsgx56ik6atues2e76ae": dial tcp [::1]:8080: connect: connection refused
Test: TestFXBlobRetrieve/blob/retrieve
=== NAME TestFXBlobRetrieve
Is caused by many of our testing "things" using 8080 as a default, and as each one spins up/down we get some thrash thus these errors. In the future, we can remove this flake by letting the OS pick a port.
pkg/pdp/service/piece_read.go
Outdated
| getOptions := []blobstore.GetOption{} | ||
| if cfg.ByteRange.Start > 0 || cfg.ByteRange.End != nil { | ||
| getOptions = append(getOptions, blobstore.WithRange(cfg.ByteRange.Start, cfg.ByteRange.End)) | ||
| } | ||
|
|
There was a problem hiding this comment.
I am going to guess this validation was added since we don't pass a range here: https://github.com/storacha/piri/pull/284/files#r2433988099 ? Seems good to have regardless.
There was a problem hiding this comment.
I think it doesn't matter actually - I added this when I had a test failure and thought this was requesting a range of 0 bytes. However you actually end up with a range 0- which is effectively the same as not specifying a range.
|
Per my previous comment about test flake, I filed #285. can rebase this change on there to clear up |
alanshaw
force-pushed
the
ash/feat/implement-access-grant
branch
from
bad4c57 to
afb0092
Compare
alanshaw
force-pushed
the
ash/feat/implement-blob-retrieve
branch
from
6cca3d9 to
9ec0bce
Compare
2 participants
This PR add a
blob/retrievecapability handler for service retrievals (see storacha/RFC#68). It is very similar to thespace/content/retrievehandler except it does accept byte range requests, only allows invocations where the resource is the service itself and is not associated with any egress billing.